No actionable comments were generated in the recent review. 🎉

sequenceDiagram
  participant Factory as get_sezm_model
  participant PropertyModel as SeZMPropertyModel
  participant CoreCompute as SeZMModel.core_compute
  participant OutputMap as fit_output_to_model_output
  Factory->>PropertyModel: construct model when fitting_net.type="property"
  PropertyModel->>CoreCompute: core_compute(..., conservative=false)
  CoreCompute->>OutputMap: convert reduced outputs without force/virial graph
  PropertyModel->>PropertyModel: translate atom_{var_name} and var_name

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Codecov Report

❌ Patch coverage is 83.15789% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.30%. Comparing base (5733301) to head (bb35245).
⚠️ Report is 5 commits behind head on master.

@@            Coverage Diff             @@
##           master    #5587      +/-   ##
==========================================
+ Coverage   82.27%   82.30%   +0.02%     
==========================================
  Files         887      888       +1     
  Lines      100331   100533     +202     
  Branches     4060     4056       -4     
==========================================
+ Hits        82550    82744     +194     
- Misses      16320    16326       +6     
- Partials     1461     1463       +2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

Thanks for adding the SeZM/DPA4 invariant property path. The eager forward contract, public key translation (atom_<var> / <var>), reduction handling, and serialization path look reasonable from code inspection.

One blocker before this can merge: the new compiled-property training test is currently failing in CI on both Python 3.10 and 3.13. The failing test is:

source/tests/pt/model/test_sezm_model.py::TestSeZMModelProperty::test_compile_matches_eager_and_backpropagates

The failure happens at loss.backward() after the compiled property forward, with a TorchInductor C++ compile error like:

torch._inductor.exc.InductorError: CppCompileError: C++ compile error
error: ‘decltype’ evaluates to ‘float’, which is not a class or enumeration type

Examples:

• Test Python (3, 3.13): https://github.com/deepmodeling/deepmd-kit/actions/runs/28181755454/job/83472993017
• Test Python (4, 3.10): https://github.com/deepmodeling/deepmd-kit/actions/runs/28181755454/job/83472993057

Since the PR exposes use_compile=True for SeZMPropertyModel and the test asserts compiled backprop works, this should either be fixed in the property compile/backward path, or the property model should explicitly fall back / reject use_compile=True until that path is supported. Otherwise users can hit a runtime compiler failure during training.

Reviewed by OpenClaw 2026.6.8 (844f405) (model: custom-chat-jinzhezeng-group/gpt-5.5)

One more documentation/example issue I noticed: doc/model/dpa4.md points to examples/water/dpa4/input_property.json as a “complete input” for property fitting, and that input uses:

"property_name": "band_prop"

with training systems ../data/data_0, ../data/data_1, ../data/data_2 and validation ../data/data_3. However, the checked-in water example data only contains box.npy, coord.npy, energy.npy, and force.npy under those systems; there is no band_prop.npy. So the advertised complete property example does not appear runnable as-is.

Could we either add matching property-label arrays for the example data, or change the docs/example wording to make clear this is a template that requires user-supplied band_prop.npy labels?

Reviewed by OpenClaw 2026.6.8 (844f405) (model: custom-chat-jinzhezeng-group/gpt-5.5)

Thanks for the follow-up fixes. I re-reviewed the current head (abce692) and the two earlier blockers look addressed:

• the compiled property test failure is now fixed; the current PR checks are green, including the Python test matrix;
• the example now points at the QM9 property subset that actually provides band_prop.npy labels, so the documented complete input is runnable.

One remaining issue I would fix before merge: the DPA4/SeZM input schema still omits sezm_ener as an allowed fitting_net.type in deepmd/utils/argcheck.py. Runtime construction accepts it in get_sezm_model() / get_sezm_spin_model() via:

if fitting_net["type"] in ("dpa4_ener", "sezm_ener"):

but the schema variant currently lists only dpa4_ener and property. That means an existing valid config using model.type: dpa4 + fitting_net.type: sezm_ener can be rejected by argument validation even though the model factory still supports it. Please add:

fitting_args_plugin.get_argument("sezm_ener"),

next to dpa4_ener in the DPA4/SeZM fitting variant.

Reviewed by OpenClaw 2026.6.8 (844f405) (model: custom-chat-jinzhezeng-group/gpt-5.5)